This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@hypercerts-org/lexicon@0.13.0

Minor Changes

• #209 8ec051f Thanks @s-adamantine! - Add app.certified.graph.follow lexicon — a social-graph follow record schema-compatible with app.bsky.graph.follow (same tid key, same subject / createdAt / optional via strongRef fields). Exports new GRAPH_FOLLOW_NSID, GRAPH_FOLLOW_LEXICON_JSON, GRAPH_FOLLOW_LEXICON_DOC, and AppCertifiedGraphFollow type namespace.

• #170 97981bd Thanks @satyam-mishra-pce! - Add cryptographic signature support to all lexicons

  Adds optional cryptographic signature support to all record lexicons, enabling platform attestation and verification that records were created through trusted services. The on-the-wire shape, signing procedure, and verification procedure all conform to Nick Gerakines' ATProtocol Attestation Specification (see also the accompanying blog post).

  New lexicons:

  • app.certified.signature.defs - Shared type definitions for signatures. Provides:
    • #list - open union array of inline signatures and com.atproto.repo.strongRef references to remote proofs
    • #inline - inline signature object with two required fields: signature (ECDSA bytes, low-S per BIP-0062, signing the record's CID) and key (DID verification method reference). The signing curve is determined by the multicodec prefix on the verification method's publicKeyMultibase, so no separate algorithm-tag field is carried on the signature itself.
  • app.certified.signature.proof - Remote attestation proof record containing the CID of the attested content (computed with the spec's $sig-repository binding).

  Changes to existing lexicons:

  All 21 record lexicons now include an optional signatures property (a ref to app.certified.signature.defs#list) placed directly on the record with no wrapper object:

  • org.hypercerts.claim.activity
  • org.hypercerts.claim.contribution
  • org.hypercerts.claim.contributorInformation
  • org.hypercerts.claim.rights
  • org.hypercerts.collection
  • org.hypercerts.context.acknowledgement
  • org.hypercerts.context.attachment
  • org.hypercerts.context.evaluation
  • org.hypercerts.context.measurement
  • org.hypercerts.funding.receipt
  • org.hypercerts.workscope.tag
  • org.hyperboards.board
  • org.hyperboards.displayProfile
  • app.certified.badge.award
  • app.certified.badge.definition
  • app.certified.badge.response
  • app.certified.actor.profile
  • app.certified.actor.organization
  • app.certified.location
  • app.certified.graph.follow
  • app.certified.link.evm

  Note on app.certified.link.evm: this record carries two orthogonal integrity primitives. The EIP-712 proof field proves wallet consent (the EVM key holder agreed to be linked to the DID). The signatures array proves record provenance (e.g. that a platform UI minted the record, defending against replay of harvested EIP-712 signatures). Both are useful and they do not conflict.

  Design notes:

  This is a non-breaking extension - signatures are optional on all records. Two signature patterns are supported:

  1. Inline signatures - Embedded directly in the record via app.certified.signature.defs#inline.
  2. Remote attestations - References to proof records in other repositories via com.atproto.repo.strongRef.

Patch Changes

• #213 80e5b42 Thanks @s-adamantine! - Clarify that knownValues is an open vocabulary, not a closed enum. Adds a "Schema Conventions" section to README.md explaining that custom string values are permitted on any knownValues field (and contrasting with enum, which is closed and validator-enforced). Updates inline descriptions on app.certified.location#locationType, org.hypercerts.workscope.tag#category, and org.hypercerts.workscope.tag#status to explicitly note that values beyond the listed set are permitted — bringing them in line with the existing wording on org.hypercerts.collection#type, org.hypercerts.context.attachment#contentType, and app.certified.badge.definition#badgeType. The locationType description now also explicitly calls out that polygons / multipolygons / featurecollections use the catch-all geojson entry rather than a typed variant. Fixes a misleading line in STRING_CONSTRAINTS.md that conflated knownValues with enum. Documentation-only — no schema or type changes.